Day 27｜一個功能怎麼走完整條 pipeline

Day 26 停在一個問題：邊界畫得出來了，那一個功能要怎麼真的走完整條線？我原本的答案很直覺：規劃、派工、測試、審查都可以交給 agent，但最後提交那一下，一定要我按。那是我替自己留的閘門。回頭查一筆實際走完的缺口，結果正好相反：這條鏈從頭到尾不需要我。那筆缺口的修正與資料提交，是無人值守的輪次自己送出去的，沒有人按。人按的那一下沒有消失，它被提前了，提前成一次寫進規則裡的事前授權。

事故：我以為的閘門，早就交出去了

先說這條鏈長什麼樣。一筆缺口進佇列時是「候選」；被挑中後變成「已選取」，負責派工的主 agent 先寫下做法，建一個備份回滾點，派執行者去改，改完自驗，再進入無人值守的審查循環。審查收斂後標成「完成」，提交，最後歸檔。

這條鏈有兩種停法。第一種是三輪上限：外層審查最多 3 輪、內層最多 2 輪，外層跑完還有紅燈，或回報出現阻擋，就不提交、反向還原、標成「延後」。第二種是其他停損點：備份失敗、自驗沒過、被危險指令攔截 hook 擋下、測試檔被忽略、本質上無法自動測，一律標延後，等下次找缺口時優先撿回。

我想要的那個閘門，條文裡確實有：互動模式下，執行前會先顯示做法，停一次等我確認。但同一份規則檔裡還有一條授權例外：無人值守流程只適用自動模式，審查收斂到 0 紅燈就自行提交並推送，限該筆的檔案集、不強制推送、逐檔加入。這條是我自己寫的。寫下它的那一刻，按鈕就交出去了，只是我當時沒意識到這件事的份量。

這次查的那一筆缺口屬於 Day 26 那個專案，不在 Day 25 計次的範圍內，是一批標錯的資料要修正。我在一個晚上用互動 session 登記它，隔天清晨被排程叫醒的無人值守輪次撿起來，一路跑到提交，中間沒有任何一步停下來等人。

也不是每一步都照條文走。執行者改檔時被攔截 hook 擋下，有直接紀錄的是 2 次；另有一筆提到第三次，但有沒有真的被擋取不到，我不算進去。條文規定這種情況要標延後並結束，禁止換一種寫法重試；實際上它換了寫檔方式，把事情做完了。這是一筆「條文未被遵守」，我記下來。

所以我真正出手的地方只有三處：事前寫下授權例外、當晚登記這筆缺口、事後手動歸檔。歸檔本來就被規定成只提示、不自動做。

證據：五百分鐘在等，五十分鐘在跑

只畫條文允許的五種狀態：候選、已選取、延後、完成、不在範圍。三輪上限與其他停損點兩條出口都通往延後。三輪上限在這次素材裡沒有實際觸發的案例，這裡只當機制畫；標著「人出手處」的三個位置是人出手的地方。

佇列的歸檔裡另有 2 筆停在條文沒有的狀態，屬於不合條文的歷史資料，沒有畫進圖裡。2026-10-04 的佇列快照中，現行 5 筆延後只有 1 筆附了原因，而且原因是要等我授權，不是撞到三輪上限。

再看這一筆缺口實際怎麼走。時間窗是登記那一晚到隔天清晨，以下數字都是我寫這篇時重新查紀錄得到的實測。

橫軸是自登記提交起的相對分鐘。橘色是有人的段落，藍色是沒人的段落；上半部是全程，下半部放大無人值守那一輪，叉號是兩次攔截。

從登記提交到最後一筆提交，總共 553.3 分鐘。其中 502.5 分鐘在等排程，真正跑的無人值守輪次是 51.1 分鐘、27 turns、正常結束；這一輪在最後一筆提交後約 20 秒才收尾，所以兩段相加略多於總數。這一輪裡由中層經理統包派工；審查第 1 輪 7.0 分鐘，修正 1.0 分鐘，審查第 2 輪 3.9 分鐘後收斂。收斂紀錄是紅 1、黃 1、藍 4，從這裡回推第 1 輪有一個紅燈。同一輪連續送出 5 筆提交，1 筆修正、4 筆資料。

圖上有人的段落只有兩塊：開頭的登記，和結尾時間取不到的手動歸檔。中間那一大段，沒有人。

兩件不利的事要一起攤開。第一，修正那筆提交比審查收斂紀錄早 9 秒。我沒辦法用時間戳證明「收斂之後才提交」的先後；收斂紀錄裡的輪數欄位也寫著 0，跟實際跑了兩輪對不上。第二是成本，這一輪有兩個口徑：單輪紀錄是 20.25 美元，逐輪用量是 26.58 美元。兩個我分開列，不相加，也不挑一個當真值。它們都是該輪次合計，同一輪也在跑其他檢查，不是這筆缺口單獨的成本；而且都是紀錄裡換算的等價成本，不是實際帳單。

解法：把按鈕換成停損點

這筆紀錄讓我改了對這條鏈的理解。我原本把安全感放在最後一步：只要提交前有人看，前面怎麼跑都沒關係。可是在無人值守模式裡，人看的那一下根本不存在；它要嘛被提前成授權，要嘛整條鏈就停在半夜等人。

所以我把重心從最後的按鈕，移到鏈上的停損點。

第一，授權例外寫得窄。只放行收斂到 0 紅燈的那一筆檔案集，不強制推送，逐檔加入。判斷一次，之後每一輪照用。

第二，每一段都有自己的出口。備份、自驗、攔截、測試、審查，各自能把這筆缺口打回延後；延後的缺口下次會優先撿回，不會消失。

第三，審查有上限。外層 3 輪、內層 2 輪，跑不完就還原。這讓最壞情況有邊界：最多白跑幾輪，不會無止境地修下去。

第四，人留在兩端。登記決定什麼值得修，歸檔確認修完的東西要收進去。這兩步不必在半夜做，也不急。

這也是我現在的看法：把規劃、派工、測試、審查、提交串成一條有停損點的鏈，比每一段各自最佳化更重要。單看任何一段，都可以再快、再便宜；但只要鏈上有一段停不下來，前面的最佳化都只是在加速出事。

新問題：跑得通，不代表跑得對

這筆缺口跑完了，紀錄看起來很漂亮：兩輪收斂、5 筆提交、正常結束。可是收斂紀錄裡那盞黃燈，是審查指出修正方向與匯入規則相反。黃燈不擋提交，所以它照樣送出去了。修完之後還有沒涵蓋到的殘留，連帶的 4 筆決策紀錄過了五天才歸檔。

再加上那 1 筆條文未被遵守：執行者被擋之後換了方式完成，整條鏈沒有任何一段把它當成失敗。

停損點只擋得住它認得的失敗。紅燈會停，阻擋會停，自驗沒過會停；但方向可疑的修正、繞過去的攔截、沒涵蓋的殘留，鏈一樣跑得通，最後一樣回報正常結束。

鏈跑得通，不代表它跑得對。那我要怎麼知道，這一年裡哪些地方曾經真的壞過？

明日預告：Day 28｜失敗盤點：這一年真正壞掉的東西